When displaying, monitoring and exploring a complex system, a Model-View-Controller (MVC) architecture is often adopted. The MVC architecture breaks up the components of a program into three entities (FIG. 1), Model 1, View 3 and Controller 2. The MVC architecture was introduced as part of the Smalltalk-80 version of the Smalltalk programming language. It was proposed to reduce the programming effort to design systems that utilized multiple views of the same data. The idea was to automatically update changes in the Model 1 in each of the associated views. The concept was later adopted in Sun Microsystems' Java MVC architecture.
Information programmably displayed that provide user interpretable information are often called “widgets”. Widgets include such things as displayed buttons, pull-down menus, icons, progress indicators, scroll bars, windows and the like. Their purpose is to provide information via graphical user interfaces (GUIs) for communicating between a program and a user. The term widget is also used to represent the small program that describes the user perceived widget.
The Model 1 is the object that represents the data in the program. It manages all data and performs all data manipulation and transformation. The model doesn't have specific knowledge of the View(s) 3 or Controller 2. The system is responsible for maintaining links between the model and its views and the system notifies the views when the model changes (due to data operations or user interactions). The View 3 is the object responsible for the presentation of Model 1 information to a user display. The View 3 interacts with the model 1 by referencing the model 1. The Controller 2 object manages interactions among the user 4, the model 1 and the view 3 by way of the user interface (UI) 5. The UI 5 presents images to the user 4 via computer displays, printers and the like and receives input from the user 4 by many means, including, but not limited to computer mouse, keyboard, touch-screen, tablet, audio, video, digital devices and computer networks. The Controller 2 interacts with the model 1 by referencing the model 1. Interactions among objects may take the form of messages sent from one object to the next. Other interaction methods are well known in the art and the invention described herein is not restricted to the example of messages.
Frequently, however, there are changes to the type and form of the information that the View 3 presents. It may change as the task the user performs evolves over time, or it may change depending on the specific task the user is performing.
For example, creating, executing and monitoring distributed applications that run on multiple hosts and are connected with a high speed data transport mechanisms, requires several views of many types of information. During initial development of the application, the user is interested primarily in the structural representation of the data flow among various applications of distributed hosts and requires views that support development. When the application is initially run (before it is completely debugged), the user is interested in both the states of the components and the interconnections between components (for example, if a component appears to be stalled, it may be because it is not running correctly or it may be because the data it requires is not being delivered, or the data it is generating is not being consumed). Unique views are needed for the debug state. Once the application is complete and the user starts running it, the user is more interested in the specific state of the components of the application (whether job steps are running or stalled, whether data transfer is occurring, and, if so, the transfer rate). When a distributed application is complete and is being used in production, the user is less interested in the specific state of the components of the applications and more interested in an overall summary of the state of the distributed job. Unique production views are needed at this stage. Controlling the overall application involves views that are similar to those required for monitoring because improperly affecting the control flow (such as abnormally terminating a component or restarting one out of sequence) can have a ripple effect that produces undesirable results.
Unfortunately, a single View 3 is not well suited to present all types of information. Graphical views are good for structure, but tend to become cluttered and unusable as specific textual information is added to them. List-type textual displays can present a lot of detailed information in a compact space, but give no information about structure. List-type textual displays are also ineffective for representing summary information (such as the progress the job is making toward completion). Measurement displays (such as bar graphs or meters) are ideal for presenting overall summaries, but give no information about structure or detailed states. In other instances, several views might be used to represent different aspects of a three dimensional object.
This has been addressed in the past in three ways. The first has been to choose a single view and add the additional information to it as needed. Typically a graphical view is chosen because it is initially easier to visualize the entire system, and mechanically it can accept the additional information that will be required later (it is easier to add text to a graphical view than graphics to a textual view). There is a practical limit to how much detailed information can be added to a graphical view as the screen real estate becomes cluttered and the information is obscured. In order to utilize this approach, a user must maintain the amount of detailed information below some threshold by selectively closing old detailed information as new information is requested.
The second approach has been to replace the View 3 object in the Model-View-Controller configuration as the type of information the user is interested in changes. When the user is no longer interested in the structure of the distributed application and becomes interested in the detailed state of the components, the structure view is replaced with a detailed state view. The problem with this approach is that the new view must be recreated on demand and inserted into the Model-View-Controller configuration. Even if the old view is preserved when the user switches out of a particular mode (switching from structure to state views, for example), there is expense involved when the old view is reused (switching back to structure from state). The old view must be reconnected with the model and controller, and it must be made current to reflect any model changes that occurred when it was not active. This expense is enough to inhibit the user from switching between views freely.
The third approach, U.S. Pat. No. 5,926,177 “Providing Multiple Views In A Model-View-Controller Architecture” assigned to International Business Machines and incorporated herein by reference, enhances the traditional MVC architecture by providing a “virtual” View (View Proxy) controlling multiple views. The View Proxy determines to which Views the model change notifications are to be sent and sends model change information to only those views effected.
In the prior art MVC architecture, a view must be designed with knowledge of the type of data it is receiving. The “translation” of data in the View object makes the View object less flexible and portable since it is expecting a specific format from the Model it is attached to. A MVC method is needed to allow the View object to be independent of data type presented by the Model.
SUN Microsystems' Java Model-View-Controller, is shown in FIG. 2, wherein the view 3 and controller 2 are combined into a single component 201. In Java it is combined into the single ComponentUI element 201. Most of the Java Swing interface widgets employ the MVC way to visualize data. This enables multiple User Interface (UI) components to translator into the same model data and be appropriately updated when changes occur. This modularity provides great flexibility
One problem with this approach is that each view must know how to interpret the model data. That knowledge, in the prior art, has been embedded in the view object.